The REST API is an architectural style and communication approach commonly used in the development of Web Services. REST is stateless, resource-based and generally runs over Hypertext Transfer Protocol (HTTP). A first issue is that the stateless-ness of REST complicates versioning or history tracking for the resources. Existing solutions for versioning and history tracking include maintaining change or “delta” information regarding document attributes that must be merged with each previous version to get a complete overview of the document at a point in time or saving previous versions in an attribute list (rather than a separate collection), which increases the size of the resource that must be retrieved, and potentially filtered, with each call by the size of the document each time a revision is made. Accordingly, a system and method that provides versioning or tracking without adding significant overhead when using the current version of the resource may be desirable.
A second issue is that REST uses a Global Unique Identifier (GUID) to identify the resources. While GUIDs are great for machines, they are not easily used by humans. For example, it is much easier for a user to use a primary key (e.g., a Media Access Control (MAC) address) that identifies a resource (e.g., a machine) than a GUID which may be a 32 bit hexadecimal number. However, a primary key may change, which could make a system using primary keys unreliable. Accordingly, a mechanism that allows use of a primary key or a GUID to identify a resource while maintaining the reliability of a GUID-only system may be desirable (e.g., to reduce network traffic or burden on a client from which the request was received).
A third issue is that REST provides no mechanism for queueing a request when an intermittent error occurs. For example, if a resource is requested and that requested resource is presently unavailable (e.g., locked), the user will receive an error message (e.g., HTTP status code 423), which the client must then handle (e.g., by retrying). Accordingly, a mechanism by which a request may be queued on the server-side and retried may be desirable.
At least one system and method are disclosed herein that at least partially address one or more of the aforementioned issues.